A method for risk analysis

Course- ERP Guide >

Risks are present and cannot always be prevented. It is however important to be aware of risks in order to control the potentially adverse effects of events in case they do occur. A good risk analysis can safeguard the attainment of the objectives of an ERP implementation, even if events have occurred that endangered realization of these objectives.

Various authors have described how a risk analysis can be executed [Kupras, 1993; COSO, 2004]. According to these authors, three steps can be distinguished in a risk analysis: risk identification, risk assessment and design of controls.

The objective of the first step in the risk analysis, the so-called risk identification, is the creation of a list of potential events that could negatively influence the attainment of the objectives of the ERP implementation. This list should at least contain the four above-mentioned risks of ERP implementations: implementation cost overruns, limited benefits realization, no financial improvement and operational problems during go live. The list should be supplemented with other project- or company-specific potential events.

The second step in a risk analysis, the risk assessment, aims to determine to which extent each of the identified risks is a threat for the attainment of the objectives of the ERP implementation. The extent to which the risk is a threat is called the severity of the risk. For each identified risk, the impact it would have on the costs and benefits during the ERP life cycle has to be estimated, as well as the probability that the event will actually occur. he impact is preferably measured in financial terms, while the probability is a number between zero and one. In a formula this becomes:

(7.1) Severityuncontrolled = Probabilityuncontrolled × Impact uncontrolled

The third and last step in the risk analysis consists of the design of control measures, or briefly controls.

The objective of a control is the reduction of the severity of a risk. A control for a risk reduces the probability that an event occurs, the impact that the event has when it occurs, or both. It is easy to see in the formula that with lower probability or impact the severity also becomes lower.

Controls generally come at a cost, which means that their side effect is decreased benefits of the ERP implementation or increased costs. For a controlled risk the following formula can be used:

(7.2) Severitycontrolled = Probabilitycontrolled × Impactcontrolled + Costcontrol

A control is economically worthwhile when:

(7.3) Severitycontrolled < Severityuncontrolled

Four classes of controls can be distinguished: evasion, reduction, transfer, and acceptance [Gevers & Hendrikxs, 2001; COSO, 2004]. he evasion of a risk means not carrying out the activities that enable the risk to occur. An example could be a company that plans to implement the Available to Promise (ATP) method for production planning in ten factories. One of the identified risks of the implementation is the required skill level of the planners: a successful implementation of ATP in a factory requires a planner with skills at university graduate level. In the smallest three of the factories, no such planners are available. As the expected benefits of ATP in these factories are small, they do not outweigh the costs of hiring extra planners. The company decides not to implement ATP in the three smallest factories. This control measure avoids the risk: it reduces the probability of the risk to zero.

The second class of controls is risk reduction. A well-known risk in ERP implementations is operational problems during the go live. In a manufacturing company, this could lead to production interruptions, which in turn could interrupt order delivery to customers. A control measure that reduces the probability of this risk to occur is an additional investment in user training before the go live; a control measure that reduces the impact is building extra safety stock just before the go live. Both controls have associated costs: more training means more time of the planners and costs for the trainers, and safety stocks means more working capital.

When a risk is transferred, a third party partially or fully takes the risk. The best-known example of risk transfer is insurance. In an ERP implementation the contracting of an ERP implementation partner on a fixed price basis is a control measure for the risk of cost overrun. he cost of this control measure is the risk margin that the implementation partner will add on top of the hourly rates that would be applicable for a time material contract.

The last class of controls is risk acceptance, simply taking the risk. In this case both the probability and the impact of the risk remain unchanged. It is clear that this is a suitable control only if the severity of the risk is low or the control measures are extremely expensive.